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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2003). All Rights Reserved. 
Abstract 


The Lightweight Directory Access Protocol (LDAP) supports a mechanism 
for requesting the return of all user attributes but not all 


operational attributes. This document describes an LDAP extension 
which clients may use to request the return of all operational 
attributes. 

1. Overview 


X.500 [X.500] provides a mechanism for clients to request all 
operational attributes be returned with entries provided in response 
to a search operation. This mechanism is often used by clients to 
discover which operational attributes are present in an entry. 


This documents extends the Lightweight Directory Access Protocol 
(LDAP) [RFC3377] to provide a simple mechanism which clients may use 
to request the return of all operational attributes. The mechanism 
is designed for use with existing general purpose LDAP clients 
(including web browsers which support LDAP URLs) and existing LDAP 
APIs. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14 [RFC2119]. 
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All Operational Attributes 


The presence of the attribute description "+" (ASCII 43) in the list 
of attributes in a Search Request [RFC2251] SHALL signify a request 
for the return of all operational attributes. 


As with all search requests, client implementors should note that 
results may not include all requested attributes due to access 
controls or other restrictions. Client implementors should also note 
that certain operational attributes may be returned only if requested 
by name even when "+" is present. This is because some operational 
attributes are very expensive to return. 


Servers supporting this feature SHOULD publish the Object Identifier 
1.3.6.1.4.1.4203.1.5.1 as a value of the ’supportedFeatures’ 
[RFC3674] attribute in the root DSE. 


Interoperability Considerations 


This mechanism is specifically designed to allow users to request all 
operational attributes using existing LDAP clients. In particular, 
the mechanism is designed to be compatible with existing general 
purpose LDAP clients including those supporting LDAP URLs [RFC2255]. 


The addition of this mechanism to LDAP is not believed to cause any 
significant interoperability issues (this has been confirmed through 


testing). Servers which have yet to implement this specification 
should ignore the "+" as an unrecognized attribute description per 
[RFC2251, Section 4.5.1]. From the client’s perspective, a server 


which does not return all operational attributes when "+" is 
requested should be viewed as having other restrictions. 


It is also noted that this mechanism is believed to require no 
modification of existing LDAP APIs. 


Security Considerations 


This document provides a general mechanism which clients may use to 


discover operational attributes. Prior to the introduction of this 
mechanism, operational attributes were only returned when requested 
by name. Some might have viewed this as obscurity feature. However, 


this feature offers a false sense of security as the attributes were 
still transferable. 


Implementations SHOULD implement appropriate access controls 
mechanisms to restricts access to operational attributes. 
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IANA Considerations 


This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the 
feature described above. This OID was assigned [ASSIGN] by OpenLDAP 
Foundation, under its IANA-assigned private enterprise allocation 
[PRIVATE], for use in this specification. 


Registration of this feature has been completed by IANA [RFC3674], 
[RFC3383]. 


Subject: Request for LDAP Protocol Mechanism Registration 


Object Identifier: 1.3.6.1.4.1.4203.1.5.1 
Description: All Op Attrs 


Person & email address to contact for further information: 
Kurt Zeilenga <kurt@openldap.org> 


Usage: Feature 
Specification: RFC3673 
Author/Change Controller: IESG 
Comments: none 
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copyrights, 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assignees. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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